Analysis of an attack on an I2P user

The history of the I2P network dates back to 2003, and therefore has become overgrown with rumors, speculation and articles about vulnerabilities, some of which are no longer relevant. Before starting the main story, we will identify solved problems, the mention of which you can still find. Don't let them bother you.

Common Misconceptions

Tale number one: I2P does not scale well and with a large increase in nodes the network will be paralyzed, because reference nodes - floodfills - cannot cope with the flow of information. They say I2P only works until it’s popular, but as soon as the total load grows, the network will collapse.

In fact, the number of floodfills grows along with the network, and to access a specific hidden service, all floodfills are not required at all. Each hidden service publishes its full address (called a LeaseSet) on the two floodfills that are closest in DHT. In turn, the DHT coordinates change every day almost randomly.
When receiving a published LeaseSet, each of the two floodfills duplicates the information to the other three floodfills, which are the closest in a logical sense. In total, the LeaseSet is published on no less than four almost random routers, which are accessed when searching for the address of a specific site or other hidden resource. In short: the network is distributed and the resources for processing LeaseSets grow along with the total number of nodes. Since the beginning of the story about the poor scalability of I2P, the network has grown many times and still remains functional without any hint of floodfill overload. It’s also worth adding that a transition to new encryption is underway, designed to reduce the load on floodfills.

Tale number two: The router on which a particular hidden service is located can be determined by the router's encryption key in the LeaseSet of the hidden resource. The model is based on the fact that onion encryption used in tunnels is not sufficient, and first of all, end-to-end encryption is applied to the message with the router key, which must decrypt the message and transmit it to the local endpoint.

It is understood that the keys for hidden services are unique, but the router has only one and, having the identifier of this key, you can track other user tunnels. In fact, this threat was eliminated in the early stages of I2P development. A modern LeaseSet contains an encryption key that is in no way connected to the router. A unique key is used for each hidden service, so comparing the keys from the LeaseSets of various hidden services of the same administrator does not give rise to assumptions that they are located on the same router.

Tale number three: I2P tunnels can be intercepted. Interception does not mean decrypting traffic, but identifying the owner of the tunnel. The attack requires the maximum possible number of routers with good uptime for their constant participation in transit tunnels. The essence of the attack is to wait for the moment when the victim’s tunnel will consist mostly (or entirely) of malicious routers. Transit nodes do not know anything about the total number of routers in the chain, but the default length of tunnels is three hops. If we assume that three routers controlled by an attacker communicate with each other within the same tunnel, he can with a high probability assume that the end link of the known chain is the owner of the tunnel.

In the event of interception of the user's outgoing tunnel, an attacker can find out where the user is accessing if, by incredible luck, at that moment he knows a LeaseSet containing data from the input tunnel of a hidden resource, which coincides with those where the information is being transmitted right now. In fact, this attack is practically impossible at the moment, when the number of nodes in the network is many tens of thousands. With any kind of tunnel interception, it is impossible to say with complete certainty that the node assumed to be the owner of the tunnel is not just another transit router. Also, such an attack cannot be called targeted, but rather random, unpredictable and very costly. The chance of any successful execution always remains negligible.

Reseed

The easiest way to combat I2P is to block resid servers, one of which is contacted for the initial network pattern when the router is first started. Resid is an archive with a number of routerInfo files, essentially a package with information about random routers through which the first user tunnels are built and the automatic expansion of the local network base begins. All resid servers are run by enthusiasts, and the resid addresses themselves are publicly available. They are accessed by domain names and known IP addresses, so collecting everything in a list and centrally blocking it is not a difficult task. However, making the first launch difficult does not mean blocking the operation of the I2P network! In case of blocking, the use of a proxy is supported when accessing the resid, which easily allows you to bypass the restrictions of the local provider. In addition, any router can be launched with an existing network base, for example, taken from another I2P router. A new step in the fight against possible blocking is the use of additional encrypted communication channels. Currently, such a tool is the Yggdrasil Network, which serves not only to access the resid, but also to fully use the I2P network. To an outside observer, Yggdrasil's activity is comparable to a VPN connection. At the time of publication of the article, work I2P via Yggdrsail and proxies are implemented only in i2pd, which is an additional argument against an outdated Java router.

The second scenario for manipulating the resid is an attempt to intercept an archive with routers on the way to the user in order to damage or replace it. The HTTPS protocol, as well as a cryptographic signature, protects against this. Certificates of resid server holders, i.e. their cryptographic identities are distributed complete with the I2P router. After receiving the start packet, the router checks its signature. If the signature matches the certificate, you can be sure that the resid has not been replaced.

Receiver holders are ordinary users, enthusiasts. They do not undergo any verification and most often remain incognito. The relevance of resid servers is regularly checked by the community and, in case of malfunction, the server will be removed from the list in the next release of the I2P router.

Sibyl Attack and Eclipse

The Sybil attack and the Eclipse attack have similar implementations. Their meaning is to flood the network with nodes controlled by the attacker, which will work for one goal: to keep the user in the sandbox. Isolation routers do not report information about regular nodes to prevent the user from breaking the blockade. This allows you to monitor the list of resources that the attacked user hosts on his router, as well as the list of those that he visits. To obtain information about the entrance tunnels of a hidden resource, you need to obtain its lysset from the nearest floodfill, as well as publish the lysset of your resource so that it can be found.

In the event of a successful attack, all user tunnels consist of nodes controlled by the attacker, as well as available floodfills. The main difference between the Sibyl attack and the Eclipse is that the Sibyl model is not aimed at a previously known user, while the Eclipse, on the contrary, implies the isolation of an initially known target. In any case, the above attack models imply the use of modified I2P routers and high literacy of the attacker. Moving away from the generalized theory, let us examine the possibility of these threats being realized..

The Eclipse attack can be considered impossible to implement in practice. This is due to the resid system, which are protected from interception. In the case when the router makes the first start with a copied network base, i.e. in fact, with a starter package not from a well-known resid, but from another I2P router, we will assume that the source is a priori reliable. It is logical to conclude that a starter package from an untrusted source should not be used. If we assume that the attacker plays the role of an enthusiast and places a well-known resid server, it should be especially noted that the I2P router uses several independent receivers, one of which is selected randomly. This makes the likelihood of a targeted attack extremely small, which makes the point of trying to carry it out lost..

A Sybil attack aimed at monitoring the network in general seems more suitable for the malicious resid model just described. But upon closer examination, it turns out that the profit of a fake resid will not recoup the funds spent on its organization. Firstly, it is necessary to have large capacities in order to introduce the maximum possible number of controlled nodes into the network. Secondly, it is necessary to develop software that will flexibly combine information collected from controlled nodes into one database. Thirdly, an attack aimed at analysis requires a long duration, which will not work, because The malicious resid will soon be identified by the community. The most obvious sign of such an attack is a non-increasing, or too small, number of known routers that is displayed in the web console. In the paranoid case, you should delete the entire local router database, which is stored in the netDb folder, and restart the router, which will trigger a new call to a random resid. If you have good reason to believe that a particular resid has been compromised, be sure to report it to the developer community. At the time of publication of this article, not a single attempt of such an attack had been registered..

Java router destination attack

The last attack model is very complex, but critically dangerous if executed successfully. The problem was disclosed by the leading developer of I2Pd and is not present in the C++ router, but has not been fixed in the Java router for a long time. The model allows you to determine the fact that two or more endpoints are on the same router, i.e. actually determine that multiple anonymous entities are physically located on the same computer. The attack possibility is that all the LeaseSets in the Java router are stored in one place.

As part of the attack, a full call is made to some endpoint (in English terminology - destination), which responds and saves the attacker's LeaseSet. The other endpoint is then contacted, but the LeaseSet for the response is not communicated, and logically there should be no response. If a response is received, the attacker can confidently conclude that the responding endpoint, which was not sent a LeaseSet to respond, is on the same router as the first resource that was given a LeaseSet.

In I2Pd, the problem is solved simply and elegantly: for each endpoint, a separate LeaseSet storage is created, which cannot be accessed by other hidden services located on the router.

Upon closer examination of the frequently mentioned threats, it turned out that there are much fewer vulnerabilities in I2P than pseudo-experts like to say. Support free projects, report bugs and shortcomings. Free software is when there is no funding and most often without advertising, but it is conscientious. Don't forget that SMS during registration is not the norm!

The material is compiled from text and illustrations from video.